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EXTENSIBLE SCHEMA FOR DEFINING THE VISUAL APPEARANCE OF 
COMPUTER SYSTEM COMPONENTS 

CROSS-REFERENCE TO RELATED APPLICATION 

[01] This application claims priority to provisional U.S. Application Ser. No. 60/196005^ 
filed April 6, 2000, which is incorporated herein by reference. 

TECHNICAL FIELD 

[02] The present invention relates generally to graphical user interfaces for computer 
systems. More particularly, the invention provides a system and method for defining 
an extensible taxonomy for graphic user controls and their visual display theme 
properties separately from the executable graphical user interface software. 

BACKGROUND OF THE INVENTION 

[03] Changing the way graphical user interface components of a computer system are 
displayed provides computer system users with a more visually exciting experience. 
This modification of the appearance of user interface components is commonly 
referred to as skinning. 

[04] Conventional skinning techniques, however, have various shortcomings. For 
instance, conventional skinning techniques typically define hard coded finite sets of 
controls in which the executable code that displays user interface components is 
intertwined with the data that specifies how the components should be displayed. 
This often leads to compatibility and performance problems between user applications 
and a computer's operating system. Further, modification of the appearance of system 
components undesirably requires modification of executable code. 

[05] Accordingly, there is a need for improved techniques for facilitating modification of 
the visual appearance of user interface components. 
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SUMMARY OF THE INVENTION 

[06] A system and method in accordance with the present invention overcomes the 
foregoing shortcomings of conventional operating system techniques for modifying 
the visual appearance of user interface components. A system theme schema file, in 
accordance with the present invention, includes declarations of enumerations, 
properties, controls, control parts, and control part states for providing extensible 
theming of the visual appearance of a computer operating system's user interface 
components. 

[07] The schema file allows new standard and custom controls, parts, states, and properties 
to be added to the a system for themeing user interface components without having to 
update other themeing system components, such as a theme authoring file parser, a 
theme loader, and/or a theme runtime property manager, which perform various 
functions to facilitate themeing of user interface components, including, but not 
limited to, parsing a schema file, parsing a theme specification file, building a binary 
version of a theme into shared memory, notifying running processes that a theme is 
active, and searching for, and returning, a theme handle that can be used to invoke 
theme drawing and information services (API's) to draw parts of a control. 

[08] Advantageously, custom theme schema files can extend the system theme schema by 
adding declarations of custom enumerations, custom properties, custom controls 
(along with their parts and states), thereby participating in theming of the visual 
appearance of various user interface components of the computer's operating system. 
The system and custom schema files establish the allowable form and content of data 
that specifies how user interface components should be displayed in accordance with 
particular themes. Themes are defined and applied to user interface components in 
accordance with the information specified in the schema files. 

[09] Additional features and advantages of the invention will be apparent upon reviewing 
the following detailed description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[10] Figure 1 is a schematic block diagram of a conventional general-purpose digital 
computing environment that can be used to implement various aspects of the present 
invention. 

[11] Figure 2 is a simplified schematic block diagram showing interaction between schema 
files and other computer system modules according to various inventive principles. 

[12] Figure 3 is a flow chart of simplified steps for implementing various aspects of the 
invention. 

[13] Figures 4-8 show a user interface button in various example states. 

DETAILED DESCRIPTION OF THE INVENTION 

[14] As mentioned above, in order to provide a visually exciting experience to the user of a 
computer operating system, it is desirable to provide a way to change the appearance 
of system components. A button, such as the button depicted in Figure 4 is an 
example of such a system component. Other user interface components for which the 
component's appearance may be changed according to certain inventive principles, 
include, but are not limited to, scrollbars, checkboxes, list views, tab controls, status 
bars, toolbars, headers, combination boxes, edit controls, progress controls, track bars, 
hyperlinks, tree views, group boxes, splitters, places bars, balloon tips, up and down 
controls, drag lists, and the like. 

[15] Modifying the appearance of such user interface components, also referred to herein 
as system components, is commonly referred to as "skinning." A theme schema file 
in accordance with certain inventive principles describes properties used by an 
operating system's drawing and information application programming interfaces 
(API's) and by theme-aware controls. The term schema refers generally to metadata, 
which is data describing other data. A schema generally defines the various parts and 
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aspects of other data, in this case, the various parts and aspects of data that are 
allowable in a theme authoring file. 

[16] Standard properties, controls, and control-specific parts, states, and custom properties 
may be defined in accordance with the schema file format such that this information 
can be referred to in the theme authoring files, the theme manager API's, and the 
theme aware drawing code. Properties generally refers herein to standard and custom 
rendering properties of user interface components, such as background image 
filename, text color, text font, and the like, 

[17] In order to allow the appearance of controls to be defined separately fi-om the control 
code itself and for additional Skemes (Skin Themes) to be defined and distributed 
separately fi-om the operating system, a Skeme definition file format is desirable. 
Following a description of an example environment in which certain inventive 
principles may be implemented, various inventive aspects will be described in the 
context of theme schema file format for use in a "WINDOWS®" operating system 
environment. Various aspects of the invention may also be used in other operating 
systems including Apple Computer's operating systems, Unix-based operating 
systems, and other operating systems. 

[18] Figure 1 is a schematic diagram of a conventional general-purpose digital-computing 
environment that can be used to implement various aspects of the present invention. 
A computer 100 includes a processing unit 110, a system memory 120 and a system 
bus 130 that couples various system components including the system memory to the 
processing unit 110. The system bus 130 may be any of several types of bus 
structures including a memory bus or memory controller, a peripheral bus, and a local 
bus using any of a variety of bus architectures. The system memory 120 includes a 
read only memory (ROM) 140 and a random access memory (RAM) 150. 

[19] A basic input/output system (BIOS) 160 containing the basic routines that help to 
transfer information between elements within the computer 100, such as during start- 
up, is stored in ROM 140. Computer 100 also includes a hard disk drive 170 for 
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reading from and writing to a hard disk (not shown), a magnetic disk drive 1 80 for 
reading from or writing to a removable magnetic disk 190, and an optical disk drive 
191 for reading from or writing to a removable optical disk 192, such as a CD ROM 
or other optical media. Hard disk drive 170, magnetic disk drive 180, and optical disk 
drive 191 are respectively connected to the system bus 130 by a hard disk drive 
interface 192, a magnetic disk drive interface 193, and an optical disk drive interface 
194. The drives and their associated computer-readable media provide nonvolatile 
storage of computer readable instructions, data structures, program modules and other 
data for the computer 100. It will be appreciated by those skilled in the art that other 
types of computer readable media which can store data that is accessible by a 
computer, such as magnetic cassettes, flash memory cards, digital video disks, 
Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), 
and the like, may also be used in the exemplary operating environment. 

[20] A number of program modules can be stored on the hard disk, magnetic disk 190, 
optical disk 192, ROM 140 or RAM 150, including an operating system 195, one or 
more application programs 196, other program modules 197, and program data 198. 
In particular, the RAM 150 will, from time to time, store various device drivers, as 
known in the art. A user can enter commands and information into computer 100 
through input or selection devices, such as a keyboard 101 and a pointing device 102. 
The pointing device 102 may comprise a mouse, touch pad, touch screen, voice 
control and activation or other similar devices. Other input devices (not shown) may 
include a microphone, joystick, game pad, satellite dish, scanner, or the like. These 
and other input devices are often connected to the processing unit 1 10 through a serial 
port interface 106 that is coupled to the system bus, but may be connected by other 
interfaces, such as a parallel port, a game port or a universal serial bus (USB). A 
monitor 107 or other type of display device is also connected to system bus 130 via an 
interface, such as a video adapter 108, In addition to the monitor, personal computers 
typically include other peripheral output devices (not shown), such as speakers and 
printers. 



Patent Application Atty. Docket No.: 03797.00025; 154594.2 

[21] The computer 100 can operate in a networked environment using logical connections 
to one or more remote computers, such as a remote computer 109. The remote 
computer 109 typically includes at least some of the elements described above relative 
to the computer 100, although only a memory storage device 1 1 1 has been illustrated 
in FIG. 1. The logical connections depicted in FIG. 1 include a local area network 
(LAN) 1 12 and a wide area network (WAN) 113. Such networking environments are 
commonplace in offices, enterprise-wide computer networks, intranets and the 
Internet. 

[22] When used in a LAN networking environment, the computer 100 is connected to local 
network 112 through a network interface or adapter 114. When used in a WAN 
networking environment, the computer 100 and remote computer 109 may both 
include a modem 115 or other means for establishing a communications over wide 
area network 113, such as the Internet. The modem 115, which may be internal or 
external, is connected to system bus 130 via the serial port interface 106. In a 
networked environment, program modules depicted relative to the computer 100, or 
portions thereof, may be stored in the remote memory storage device. 

[23] It will be appreciated that the network connections shown are exemplary and other 
means of establishing a communications link between the computers can be used. 
The existence of any of various well-known protocols, such as TCP/IP, 
"ETHERNET", FTP, HTTP and the like, is presumed, and the system can be operated 
in a client-server configuration to permit a user to retrieve web pages from a web- 
based server. Procedures of the present invention to be described below can operate 
within the environment of the computer 100 shown in FIG. L Although the invention 
is generally applicable to a computer operating in accordance with the IEEE 1394 
standard, it is not intended to be so limited. 

[24] Figure 2 is a simplified block diagram depicting relationships among various files in 
accordance with various inventive principles. System theme schema file 200, which 
is named TmSchema.h" in Figure 2, may be a "C" programming language header file. 
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As described in more detail below, the system schema file may define a common set 
of enumerations, properties, class names, class parts, and class states that specify an 
allowable form and/or an allowable content for system or base theme related data to 
be shared among various modules for displaying user interface or system components 
in accordance with the system theme schema. 

[25] The first part of the system schema file may contain some fixed information such as 
definitions of various constants. This first part of the system schema file may also 
include a header file defining macros, constants, and structures useful for simplifying 
and increasing the readability of the system schema file. The contents of an example 
of such an include file, which may be named SchemaDefh, are reproduced below: 

// 

// SchemaDefh - defines needed to build a Theme Manager schema 
// file 

//. 

#ifndef SCHEMA_STRINGS // FIRST PASS of this hdr file 
// 

#ifhdef SCHEMADEF_H 
#define SCHEMADEF_H 

//. 

#defme SCHEMADEF_VERSION 1 // defines the exported fiinc(s) implemented 

//. 

struct TMPROPINFO 

{ 

LPCWSTR pszName; 
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SHORT sEnumVal; 
BYTEbPrimVal; 

}; 

//. 

struct TMSCHEMAINFO 
{ 

DWORD dwSize; // size of this struct 

int iSchemaDefV ersion; // version number from this file 

int iThemeMgrVersion; // version number from "thschema.h" 

int iPropCount; // # of entries in prop table 

const struct TMPROPINFO *pPropTable; // ptr to prop table 

}; 

// 

#defme BEGIN_TM_SCHEMA(name) 

#define BEGIN_TM_PROPS0 enum PropValues { DummyProp = 49, 

#define BEGIN_TM_ENlJM(name) enum name { 

#defme BEGIN_TM_CLASS_PARTS(name) enum name##PARTS { 

name##PartFillerO, 
#defme BEGIN_TM_PART_STATES(name) enum name##STATES { 

name##StateFillerO, 
#define TM_PROP(prefix, name, primval) prefix##_##name, 
#defme TM_ENUM(prefix, name) prefix##_##name, 
#defme TM_PART(prefix, name) prefix##_##name, 
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#define TM_STATE(prefix, name) prefix##_##name, 
#define TM_PARTVAL(prefix, name, val) prefix##_##name = val, 
#defme END_TM_CLASS_PARTS() } ; 

#define END_TM_PART_STATES() } ; 

#defme END_TM_PROPS0 } ; 

#define END_TM_ENUMO } ; 

#define END_TM_SCHEMA(name) 

//. 

#endif // SCHEMADEF_H 

//. 

#else // SECOND PASS of this hdr file 

// 

#undefBEGIN_TM_SCHEMA 

#imdefBEGIN_TM_PROPS 

#undefBEGIN_TM_ENUM 

#undefBEGIN_TM_CLASS_PARTS 

#undefBEGIN_TM_PART_STATES 

#undefTM_PROP 

#undefTM_PART 

#undefTM_STATE 

#imdefTM_PARTVAL 

#undefTM_ENUM 

#undef END_TM_CLASS_PARTS 
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#undefEND_TM_PART_STATES 
#undefEND_TM_PROPS 
#undefEND_TM_ENUM 
#undefEND_TM_SCHEMA 

//. 

#defme BEGIN_TM_SCHEMA(name) static const TMPROPINFO name[] = 

{ 

#define BEGIN_TM_PROPS() 

#define BEGIN_TM_ENUM(name) {L#name, TMT_ENUMDEF, 

TMT_ENUMDEF}, 
#define BEGIN_TM_CLASS_PARTS(name) {L#name L'TARTS", 

TMT_ENUMDEF, TMT_ENUMDEF}, 
#define BEGIN_TM_PART_STATES(name) {L#name L"STATES", 

TMT_ENUMDEF, TMT_ENUMDEF}, 
#deiine TM_PROP(prefix, name, primval) {L#name, prefix##_##name, 

TMT_##primval}, 
#define TM_PART(prefix, name) {L#name, prefix##_##name, 

TMT_ENUMVAL}, 
#defme TM_STATE(prefix, name) {L#name, prefix##_##name, 

TMT_ENUMVAL}, 
#define TM_PARTVAL(prefix, name, val) {L#name, prefix##_##name, 

TMT_ENUMVAL}, 
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#define TM_ENlJM(prefix, name) {L#name, prefix##_##name, 

TMT_ENUMVAL}, 
#define END_TM_CLASS_PARTS() 
#define ENDTMPARTSTATESQ 
#define END_TM_PROPS0 
#define END_TM_ENUM() 
#define END_TM_SCHEMA(name) }; \ 

static const TMSCHEMAINFO *GetSchemaInfo() \ 

{ \ 

static TMSCHEMAINFO si = {sizeof(si)}; \ 
si.iSchemaDefVersion = SCHEMADEF_VERSION; \ 
si.iThemeMgrVersion = THEMEMGR_VERSION; \ 
si.iPropCount = sizeof(name)/sizeof(name[0]); \ 
si.pPropTable = name; \ 
\ 

return &si; \ 

} 

//. 

#endif 

//. 

[26] In accordance with various inventive principles, both strings and enumeration values 
for each listed property are defined in a single table using a special two-pass include 
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technique. Conventionally, such strings and enumeration values must be defined in 
two separate, but similar, tables, which undesirably get out of sync and "break" when 
the separate tables are not uniformly updated. This two-pass, single table technique 
advantageously calls for maintenance of only a single occurrence of each property 
while providing the benefit of having two tables, including increased readability of 
the system schema file and related files. An example of a beginning portion of a 
theme manager schema file, TmSchema.h, in accordance with various inventive 
principles, is set forth below: 

//_„ 

// TmSchema.h - Theme Manager schema (properties, parts, etc) 
//__ 

// Note: this file is normally #include-ed twice a single .cpp 



// file. The 2nd time, SCHEME_STRINGS should be defined. 

// This allows the enums and strings to be kept in a 

// single logical table and ensure they stay in sync with 

// each other. 



// 

#if (defined { SCHEMA__STRINGS ) ) 1| (! def ined {TMSCHEMA_H) ) 

// 

#define TMSCHEMA__H 

// 

# include "SchemaDef . h" 

// 

idefine THEMEMGR_VERSION 1 // increment if order of props changes or 

// any props are deleted (will prevent 

loading 

//of controlsets that use older version 
// 
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BEG IN_TM_SCHEMA (ThemeMgr Schema) 

// 

// TM_ENUM (also declared in PROPERTIES section) 

// 

[27] Following the beginning portion of the system schema file, the system schema file 
may then define enumerations having an enumeration name and a set of named 
values. An example enumeration definition is: 

BEGIN_TM_ENUM(BGTYPE) 

TM_ENUM(BT, IMAGEFILE) 

TM_ENUM(BT, BORDERFILL) 

TM_ENUM(BT, NTLFILE) 
END_TM_ENUM() 

[28] This example declares an enumeration called "BGTYPE" that has 3 named values: 
IMAGEFILE (value=0), BORDERFILL (value=l), and NTLFILE (value=2). 

[29] The system schema file may also include a section defining a set of properties based 
on primitive data types or based on a previously declared enumeration. In order to 
work with the previously mentioned included macro definitions, this section may 
include a line at the beginning of this section that says, "BEGIN TM PROPS ()" and 
a line at the end of this section that says "END_TM_PROPS ()." An example 
property definition is: 

TM_PROP(TMT, BORDERSIZE, INT) 

[30] This example property definition declares a "BorderSize" property of type "int." 
Another example property definition is:TM_PROP(TMT, BGTYPE, ENUM) 

[31] This example property definition declares a "BgType" property of type "enum." 
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[32] When the schema file is compiled, each property will be assigned an enumeration 
value (e.g„ the property "BorderSize" would be represented by the enum symbol 
"TMT_BORDERSIZE" whose value would be "2403") that can be used both by the 
control code as well as the theme rendering code, to exchange information about 
standard or custom properties that may appear in the runtime theme file. 

[33] Also, when the schema file is compiled in the theme manager, each property will 
produce an entry into the theme loader's symbol table, describing the name, 
enumeration number, and type of the property. 

[34] The system schema file may also include a section containing the name of user 
interface control classes, along with their part and state declarations, also referred to 
herein as declarations or definitions of parts and states. An example parts declaration 
is: 

BEGIN_TM_CLASS_PARTS(BUTTON) 

TM_PART(BP, PUSHBUTTON) 

TM_PART(BP, RADIOBUTTON) 

TM_PART(BP, CHECKBOX) 

TM_PART(BP, GROUPBOX) 

TM_PART(BP, USERBUTTON) 
END_TM_CLASS_PARTS() 

[35] This example defines a class called "button" that has the 5 specified parts. 

[36] An example declaration of part states is: 

BEGIN_TM_PART_STATES(PUSHBUTTON) 
TM_STATE(PBS, NORMAL) 
TM_STATE(PBS, HOT) 
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TM_STATE(PBS, PRESSED) 
TM_STATE(PBS, DISABLED) 
TM_STATE(PBS, DEFAULTED) 
END_TM_PART_STATES() 

[37] This example defines a part called "pushbutton" that has the 5 specified states. Five 
example buttons in possible renderings of these respective states are shown in Figure 
4-8. Of course, other suitable renderings of these states are also possible. 

[38] Following the parts and states definitions, the system schema file may have an ending 
section containing the following: 

END__TM_SCHEMA(xxx) 
[39] where "xxx" is the schema name. 

[40] The enumerations, properties, and control parts and control part states, as 

described above, establish, in a sense, a vocabulary that may be used in a theme 
authoring file to specify how various controls, which may include one or more parts, 
should look according to a particular theme. 

[41] Referring to Figures 2 and 3, in accordance with certain inventive principles, system 
schema file (TmSchema.h) 200 is compiled into: theme manager DLL (UxTheme.dll) 
202-1, common controls DLL (ComCtl32.dll) 204, and theme packager 
(PackThem.exe) 214. This may occur at system build time, as depicted at step 300 in 
Figure 3. System schema file (TmSchema.h) 200 may also be compiled into 
computer operating system code and/or third-party custom control code (DLL, LIB, 
or EXE files). 

[42] According to certain inventive principles, a control author may define a custom theme 
schema, which may be contained in custom schema file (Custom3.h) 216. The 
custom schema may define enumerations, properties, parts, and states in addition to 
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those defined in the system schema file, thereby effectively extending the system or 
base theme schema. The custom theme schema may then be compiled into one or 
more custom themed controls, such as custom control DLL (Custom3.dll) 218, as 
depicted in Figure 2 and at step 302 in Figure 3. The custom control DLL may be 
registered as a "path" value under the registry key: 
HKEY_LOCAL_MACHINE\Software\MicrosomWindows\CurrentVersion\ThemeM 
anager\CustomControls. An example path is: "c:\program files\acme\keypad.dH". 

[43] A theme author may then create a theme description (Default.ini) 210, also referred to 
herein as the theme authoring file. Package theme file (custom3.mstheme) 220 may 
then be generated by theme packager (PackThem.exe 214) in accordance with the 
system theme schema, the custom theme schema, and the theme description, as 
depicted at step 304. As part of generating the packaged theme file, the theme 
packager may extract schemas fi-om custom controls registered with the theme 
manager. The theme manager may then validate the contents of the theme authoring 
file based upon the contents of both the system schema information and the custom 
schema information, as depicted at step 306. This may be accomplished in part by the 
theme packager attempting to call registered custom control DLL's to get their 
respective custom theme schema information. According to certain inventive 
principles, the theme packager implements these DLL calls automatically when the 
system theme schema file and any custom theme schema files are built in accordance 
with the example schema file format set forth above. 

[44] At step 308, a determination is made as to whether it is time to load a theme. A theme 
may be loaded upon starting an operating system and when a user indicates that a 
change is desired from a current theme to a different theme. At step 310, when it is 
time to load a theme, the theme manager loads registered custom control DLL's, re- 
validates the property information in the theme authoring file, and maps the properties 
and their values into a binary theme format 206 (Figure 2). 
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[45] As depicted at steps 312 and 314, when it is time to display a common control, 
information, such as the common control's properties, part information, and state 
information, is passed to the theme manager. The theme manager interprets this 
information and displays the common control in accordance with the base schema 
defined in the system schema file. 

[46] Similarly, as depicted at steps 316 and 318, when it is time to display a custom 
control, information, such as the custom control's properties, part information, and 
state information, is passed to the theme manager. The theme manager interprets this 
information and displays the custom control in accordance with the custom schema 
loaded fi^om the control at load time. 

[47] What has been described above is merely illustrative of the application of the 
principles of the present invention. Those skilled in the art can implement other 
arrangements and methods without departing from the spirit and scope of the present 
invention. Any of the methods of the invention can be implemented in software that 
can be stored on computer disks or other computer-readable media. No claim should 
be interpreted to be in means plus function format. Numbered steps in method claims 
should not be interpreted to require a particular ordering of the steps. 
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